复杂关系场景,图数据库为何是首选?


                                                                                                                                                <blockquote> 

关于作者:张潇老师,10 年全职 DBA,3 年数据库产品经理,目前担任证券行业数据治理与数据技术。墨天轮ID“多明戈教你玩狼人杀”。本文源自张潇老师在北京 nMeetUp 上的分享。

图片

从关系视图炼狱到关系图谱自由:手把手教业务部门用图数据库逆袭》一文曾经提到,关系型数据库与现实中的关系往往存在一个鸿沟,那么我们今天再次展开,从理论出发,来聊聊关系型数据库无法直观显示“关系”的悖论。

本文首发于「NebulaGraph 技术社区」,更多产品资讯请访问「NebulaGraph 官网」

一、为何“关系”成为数据库的阿喀琉斯之踵?

阿喀琉斯之踵(Achilles’ Heel),原指阿喀琉斯的脚后跟,因是其身体唯一一处没有浸泡到冥河水的地方,成为他唯一的弱点。阿喀琉斯后来在特洛伊战争中被毒箭射中脚踝而丧命。现引申为致命的弱点、要害。

如果大家做过面向对象编程,那么对于关系型数据库的表以及类之间的异曲同工会有心得。本质上,这两者都是对于现实世界各种属性的抽象和建模。它们在软件开发中常常被一起使用,也能够印证其中的关联。

然而,如果我想要表达两个实体之间的“关系”又该怎么办?比如客户经理 A 服务于客户 A,客户经理助理 A 又服务于客户经理 A?那么我们往往会创建三张表,分别代表三个不同的角色,再使用外键或者维护一张关系表来做关系的对应。

图片

图片

图片

图片

那么,我想要获取某个客户是哪个客户经理服务,这个客户经理又有哪些客户经理助理,就需要一个多表 JOIN:

SELECT 
    c.customer_name AS 客户名称,
    m.manager_name AS 客户经理姓名,
    ma.assistant_name AS 助理姓名,
    m.manager_email AS 客户经理邮箱,
    ma.assistant_email AS 助理邮箱
FROM 
    customers c
JOIN 
    customer_manager_relationship cmr ON c.customer_id = cmr.customer_id
JOIN 
    managers m ON cmr.manager_id = m.manager_id
JOIN 
    manager_assistants ma ON m.manager_id = ma.associated_manager_id
WHERE 
    c.customer_name = '客户 A'; 

三张表的 JOIN,就意味着随着数据量的提升,有可能出现查询性能的断崖式下滑。过往很多互联网公司,往往会有不允许超过几张表的 JOIN 的“军规”就是来自于此。

这背后的本质在于,外键无语义描述能力,无法表达关系的强度、类型等属性,难以满足复杂关系的存储需求。即便是如今关系型数据库已经如此强大,仍然有着它们无法有效覆盖到的场景。

然而,人际关系的复杂之处就在于此,我们现实中的人际关系是动态的网状结构,非静态层级,随时可能发生变化,难以用传统的表结构来准确表述——我遇见谁会有怎样的对白,我等的人她在多远的未来。

就比如 Jack Ma 背后有哪些企业和关联人,这些关联的任何企业具体和他又是什么关系,用关系型数据库可以表述,但是在查询时带来的复杂度以及性能开销,都是远超我们想象的。其中任何一环有了变化,都会引起滚雪球一样的修改。

暂无图片

(用图来表示 Jack Ma 和其企业的关系)

二、图数据库:存储逻辑的重构哲学

我们仍然从理论出发,图数据库表达“关系”时,有哪些先天优势。

(一)图数据库三要素天然适配关系

顶点:人/物(携带属性),如姓名、年龄等,是关系的主体。一个顶点有时候更像关系型数据库中的一条记录,包含了属性,同时代表一个确定的实体。

:关系(可携带权重、类型),如亲密度、时间等,是关系的连接。边在关系型数据库里怎么直接描述?外键或者其他方式的引用,但是图数据库中,一条记录足以,甚至表达更加简练精确。

属性:为顶点和边提供详细信息,丰富关系的语义。顶点和边都可以带属性,比如顶点里人有年龄有身高,边的属性里有关系的走向以及关系的具体定义等等。

那么与关系型数据库相比,图数据库的差异就很明显:
1. 关系表达:关系型数据库采用隐式表达(外键约束),图数据库采用显式(一等公民)直接存储关系。
2. 查询模式:关系型数据库集合操作,图数据库图遍历。

(二)图数据库查询语言深度挖掘隐藏信息

既然关系表达和查询模式存在差异,那么必然就会带来查询语言的不同,SQL 查询作为结构化查询,有着自己先天的优势,但是在面对复杂关系时,就会有自己的局限性。

比如,查询黄晓明和李晨的关系,以及他们有没有共同的朋友或者间接合作的企业,SQL 语言就存在局限:需要显式指定 Join 路径,并且路径固化,难以应对动态关系查询。

那么如果用图数据库语言来查询,不但代码简洁,还可以通过查询关系深度挖掘到更多不同的信息。

此外,在黄晓明和李晨的关系中,深度一度,可以获取他们直接的商业关联,二度还可以发现共同的朋友以及互相的商业关系——这是 SQL 语言不擅长的。

图片

(用 NebulaGraph 进行某公司股权穿透)

三、NebulaGraph 如何重构关系存储

首先我们还是拿开篇提到的:客户、客户经理、客户经理助理三者关系,来规划一下图数据库的模型:顶点(tag)代表实体,边(edge)代表关系,而两者有各自属性(Property)。

那么我想查询某个客户关联的关系,该怎么查?

-- 查询客户A的客户经理及其助理信息
MATCH (c:Customer {customer_name: '客户A'})-[:Managed_By]->(m:Manager)-[:Assisted_By]->(a:Assistant)
RETURN c.customer_name AS 客户名称, m.manager_name AS 客户经理姓名, a.assistant_name AS 助理姓名, m.manager_email AS 客户经理邮箱, a.assistant_email AS 助理邮箱;

不需要考虑多表 Join 的逻辑,只需要找到客户姓名是客户 A 的客户,对应关系是 Managed_By 的客户经理以及关系是 Assisted_By 的客户经理助理即可,而因为是遍历,性能方面比起多表 join 也有了很强的性能提升。用 NebulaGraph ,上万条信息记录,可实现毫秒级查询。

为实现在处理千亿节点万亿条边的超大数据集时,也能提供毫秒级查询的解决方案,NebulaGraph 在核心设计上做出了多项关键努力:

图片

架构层面:采用存算分离架构,支持计算层与存储层的独立、灵活扩缩容,有效应对负载变化与数据增长。

数据模型层面:提供强 Schema 的灵活属性图模型,支持对点、边、及其属性进行便捷的定义、添加与修改,满足复杂业务建模需求。

查询模式层面:基于原生图存储引擎与免索引邻接的核心优势,通过高效的图遍历模式查询,使得在深度关联查询(尤其是多跳查询)场景下,随着数据规模的增长,其性能优势相比传统关系型数据库愈发显著。

四、NebulaGraph 的应用

在过去的一段时间里,我做了如下探索和测试:

社交网络分析
1. 合规检测:识别洗钱或黑产团伙,通过关联的设备或者账号,在反洗钱方面的应用。
2. 人际关系分析:关键节点挖掘,例如高净值客户识别,通过股权穿透、周围强人际关系等等。

金融风控
1. 实时反欺诈:闭环交易检测,在关系型数据库中不能直观反映的A→B→C→A路径分析。
2. 知识图谱构建:比如企业股权穿透,让多层持股关系可视化。

Graph+AI(规划中)
1. GraphRAG:知识图谱增强大模型推理,这部分具体怎么做还想看看其他同行的探索。
2. Text2 GQL:自然语言转查询语句,目的是让业务部门自助完成各类数据查询工作。

五、结语

总之,当你需要处理大规模复杂关系数据并追求高效查询时,NebulaGraph 作为一款开源分布式图数据库,能够有效解决这一核心挑战

最后依旧要强调,每一种数据库有着自己的擅长的领域与场景,我们去研究关系型数据库、文档数据库、图数据库,最终目的不是为了谁替代谁,而是在不同场景里综合选择当下最合适的方案。

本文首发于于「NebulaGraph 技术社区」,更多产品资讯请访问「NebulaGraph 官网」

✨更多关系型数据库与图数据库的对比,可查看官网

https://www.nebula-graph.com.cn/posts/graph-database-vs-relational-database

 

                                                                                </div>


维权提醒:如果你或身边的朋友近五年内因投顾公司虚假宣传、诱导交费导致亏损,别放弃!立即联系小羊维权(158 2783 9931,微信同号),专业团队帮你讨回公道! 📞立即免费咨询退费


Source link

未经允许不得转载:紫竹林-程序员中文网 » 复杂关系场景,图数据库为何是首选?

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
关于我们 免责申明 意见反馈 隐私政策
程序员中文网:公益在线网站,帮助学习者快速成长!
关注微信 技术交流
推荐文章
每天精选资源文章推送
推荐文章
随时随地碎片化学习
推荐文章
发现有趣的